圖1. recap (source: https://www.beyondcorp.com/)

前幾回我們談到了 BeyondCorp 架構中的基礎元件——設備/身份數據庫，以及模擬外網的非特權網路。所以目前整個架構地圖已經點亮了最基本的 devices 和 network。接下來的問題是，我怎麼知道他是可以連線的受信任的 device 或用戶呢？我怎麼知道誰是安全可以進到後端應用程序，而誰應該要被擋下來呢？

在所有內部服務中 enforce company policy 是一個顯著的挑戰。

爲了應對這一挑戰，Google 透過一個集中式策略執行的 front-end Access Proxy (AP) 來處理粗粒度的 company policy。

圖2. Access Proxy (source: https://www.beyondcorp.com/)

Access Proxy 是整個 BeyondCorp 架構或者說整個 Google Global Network 的核心，簡單來說就是用戶訪問會先到這個 Access Proxy，訪問在此接受 authorization、authentication、access control checks、 application checks，和 load balancing 等洗禮，成功後便被導到後端。實現這個 Access Proxy 靠的是 Google Front-ends (GFEs), 也是 Google Load balancer 的底層技術。不過這個我們明天再提。我們這篇先來看一下第一篇論文是怎麽介紹 Access Proxy 的。（爲了達到一個平滑的學習曲線，我們要先從簡單的開始學起，也因爲我沒時間寫完。。。）

本篇大部分爲論文翻譯，詳見出處：An overview: "A New Approach to Enterprise Security"。

將應用程序和工作流外部化

Internet-Facing Access Proxy

在Google，所有企業應用程序都會通過一個 Internet-facing access proxy 向外部和內部客戶端開放，該 proxy 會在客戶端和應用程序之間強制執行加密，提供的功能包含但不限於：global reachability、load balancing、access control checks、application health checks、and denial-of-service protection。在 access control checks 完成後，proxy 會根據需要將請求轉交給後端應用程序。

Access Proxy 完美體現了 BeyondCorp 的精神——沒有網路邊界的概念——對內外網一視同仁，要訪問後端應用都必須經過 Access Proxy 做認證、授權和分流。

Public DNS Entries

Google 的所有企業應用程序都對外公開，並在公共 DNS 中注冊。其中，DNS record 的 CNAME 將應用程序指向 Internet-Facing Access Proxy。

也就是說，DNS 上的 record 不是直接指向後端應用程序，而是指向 Access Proxy，讓 Access Proxy 進行集中式的安全管控、認證、授權、訪問控制，把合法的請求轉交給對應的後端應用程序。

然而 Proxy Server 概念看似簡單，實際上要達到上述功能並非易事。例如，我們都知道要做身份驗證和授權，但具體是怎麽做的？這種集中式授權有沒有短板？後端又是怎麽去確保所接收的用戶訪問確實是經過驗證和授權的？帶著這些疑問，我們可以在第三篇論文裡找到想要的答案。（沒錯我們要 dive into the question of how does it work ><!!）

第一篇論文 An overview: "A New Approach to Enterprise Security" 只是簡單介紹 Access Proxy，而第三篇論文 Google's frontend infrastructure: "The Access Proxy" 則是回答了上面的疑問，詳細說明了具體 Access Proxy 的功能是如何實現的、中途遇到了什麼問題、如何解決這些問題、有哪些 lessons learned 等。

明天我們來看第三篇論文。會講到 Google front-ends (GFEs)!! 是不是超興奮的~~~
明天見！